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Abstract 
This document describes a pseudowire encapsulation for Time Division 
Multiplexing (TDM) bit-streams (T1, El, T3, E3) that disregards any 


Structure that may be imposed on these streams, in particular the 
structure imposed by the standard TDM framing. 
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1. Introduction 


This document describes a method for encapsulating Time Division 
Multiplexing (TDM) bit-streams (T1, El, T3, E3) as pseudowires over 
packet-switching networks (PSN). It addresses only structure- 
agnostic transport, i.e., the protocol completely disregards any 
structure that may possibly be imposed on these signals, in 
particular the structure imposed by standard TDM framing [G.704]. 
This emulation is referred to as "emulation of unstructured TDM 
circuits" in [RFC4197] and suits applications where the PEs have no 
need to interpret TDM data or to participate in the TDM signaling. 


The SAToP solution presented in this document conforms to the PWE3 
architecture described in [RFC3985] and satisfies both the relevant 
general requirements put forward in [RFC3916] and specific 
requirements for unstructured TDM signals presented in [RFC4197]. 


As with all PWs, SAToP PWs may be manually configured or set up using 
the PWE3 control protocol [RFC4447]. Extensions to the PWE3 control 
protocol required for setup and maintenance of SAToP pseudowires and 
allocations of code points used for this purpose are described in 
separate documents ([TDM-CONTROL] and [RFC4446], respectively). 


2. Terminology and Reference Models 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2.1. Terminology 


The following acronyms used in this document are defined in [RFC3985] 
and [RFC4197]: 


ATM Asynchronous Transfer Mode 

CE Customer Edge 

CES Circuit Emulation Service 

NSP Native Service Processing 

PE Provider Edge 

PDH Plesiochronous Digital Hierarchy 
PW Pseudowire 

SDH Synchronous Digital Hierarchy 
SONET Synchronous Optical Network 

TDM Time Division Multiplexing 
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In addition, the following TDM-specific terms are needed: 


o Loss of Signal (LOS) - a condition of the TDM attachment 
circuit wherein the incoming signal cannot be detected. 
Criteria for entering and leaving the LOS condition can be 
found in [G.775]. 


o Alarm Indication Signal (AIS) - a special bit pattern (e.g., as 
described in [G.775]) in the TDM bit stream that indicates 
presence of an upstream circuit outage. For El, T1, and E3 
circuits, the AIS pattern is a sequence of binary "1" values of 
appropriate duration (the "all ones" pattern), and hence it can 
be detected and generated by structure-agnostic means. The T3 
AIS pattern requires T3 framing (see [G.704], Section 
2.5.3.6.1) and hence can only be handled by a structure-aware 
NSP. 


We also use the term Interworking Function (IWF) to describe the 
functional block that segments and encapsulates TDM into SAToP 
packets and that in the reverse direction decapsulates SAToP packets 
and reconstitutes TDM. 


2.2. Reference Models 


The generic models defined in Sections 4.1, 4.2, and 4.4 of [RFC3985] 
fully apply to SATOP. 


The native service addressed in this document is a special case of 


the bit stream payload type defined in Section 3.3.3 of [RFC3985]. 


The Network Synchronization reference model and deployment scenarios 
for emulation of TDM services are described in [RFC4197], Section 
4.3. 


3. Emulated Services 


This specification describes edge-to-edge emulation of the following 
IDM services described in [G.702]: 


El (2048 kbit/s 
T1 (1544 kbit/s 
E3 (34368 kbit/s 
T3 (44736 kbit/s 


; this service is also known as DS1 


心 UN ER 


; this service is also known as DS3 
The protocol used for emulation of these services does not depend on 


the method in which attachment circuits are delivered to the PEs. 
For example, a T1 attachment circuit is treated in the same way 
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regardless of whether it is delivered to the PE on copper [G.703], 
multiplexed in a T3 circuit [T1.107], mapped into a virtual tributary 
of a SONET/SDH circuit [G.707], or carried over an ATM network using 
unstructured ATM Circuit Emulation Service (CES) [ATM-CES]. 
Termination of any specific "carrier layers" used between the PE and 
CE is performed by an appropriate NSP. 


4. SAToP Encapsulation Layer 
4.1. SAToP Packet Format 
The basic format of SAToP packets is shown in Figure 1 below. 


0 1 2 3 
06 78 9-01 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


PSN and PW demultiplexing layer headers | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


一 一 一 一 十 
SATOP Encapsulation Header | 
== 一 一 十 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


十 
| 
| 
| 
+ 
| 
+ 
| 
+ 
| 
+ 
| 


TDM data (Payload) 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Figure 1. Basic SAToP Packet Format 

4.2. PSN and PW Demultiplexing Layer Headers 
Both UDP and L2TPv3 [RFC3931] can provide the PW demultiplexing 
mechanisms for SAToP PWs over an IPv4/IPv6 PSN. The PW label 
provides the demultiplexing function for an MPLS PSN as described in 
Section 5.4.2 of [RFC3985]. 
The total size of a SAToP packet for a specific PW MUST NOT exceed 
path MTU between the pair of PEs terminating this PW. SAToP 


implementations using IPv4 PSN MUST mark the IPv4 datagrams they 
generate as "Don't Fragment" [RFC791] (see also [PWE3-FRAG]). 
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4.3. SAToP Header 


The SAToP header MUST contain the SAToP Control Word (4 bytes) and 
MAY also contain a fixed RTP header [RFC3550]. If the RTP header is 
included in the SAToP header, it MUST immediately follow the SAToP 
control word in all cases except UDP multiplexing, where it MUST 
precede it (see Figures 2a, 2b, and 2c below). 


Note: Such an arrangement complies with the traditional usage of RTP 
for the IPv4/IPv6 PSN with UDP multiplexing while making SAToP PWs 
Equal Cost Multi-Path (ECMP)-safe for the MPLS PSN by providing for 
PW-IP packet discrimination (see [RFC3985], Section 5.4.3). 
Furthermore, it facilitates seamless stitching of L2TPv3-based and 
MPLS-based segments of SAToP PWs (see [PWE3-MS]). 


0 1 2 3 
01.2 347506798 9012345078 9012 3450798 9 01 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


IPv4/IPv6 and UDP (PW demultiplexing layer) headers | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


=> OPTIONAL E 


Fixed RIP Header (see [RFC3550]) E 


+ 


SAToP Control Word 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


十 
十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 = 十 | 
| 

TDM data agora) | 


+ 
| 
| 
| 
+ 
| 
+ 
| 
+ 
| 
+ 
| 
+ 
| 
| 
| 
+ 


一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure 2a. SAToP Packet Format for an IPv4/IPv6 PSN with 
UDP PW Demultiplexing 
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0 1 2 3 
01.2- 3-4 5.67 8 9 0.1 2 3 4 5 6 7 89 9.0 12 3 4-36 7 8 9.0 1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| IPv4/IPv6 and L2TPv3 (PW demultiplexing layer) headers | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| SAToP Control Word | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
十 
十 
十 


FA OPTIONAL ==+ 
一 一 Fixed RIP Header (see [RFC3550]) 一 一 十 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


TDM data (Payload) 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure 2b. SAToP Packet Format for an IPv4/IPv6 PSN with 
L2TPv3 PW Demultiplexing 


0 1 2 3 
0012.34 506 T:8.9-0.12 2 34 5 6 48 9 0 2 32 050618. 9 «0.1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


MPLS Label Stack 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
SATOP Control Word 
十 三 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


T 
b 
Jl 
T 
Ed 


dl 
a 
N 
T 
T 


OPTIONAL 


| 
| 
一 + 一 + 一 + 一 + 一 十 


Fixed RIP Header (see [RFC3550]) 


i 
M 
M 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


DS E EE 
| 
十 


TDM data (Payload) 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure 2c. SAToP Packet Format for an MPLS PSN 
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4.3.1. Usage and Structure of the Control Word 
Usage of the SAToP control word allows: 


1. Detection of packet loss or misordering 

2. Differentiation between the PSN and attachment circuit problems 
as Causes for the outage of the emulated service 

3. PSN bandwidth conservation by not transferring invalid data 
(AIS) 

4. Signaling of faults detected at the PW egress to the PW 
ingress. 


The structure of the SAToP Control Word is shown in Figure 3 below. 


0 1 2 3 
QUT 2435 45:06: 28979 00:12 3745-678 9.071 2. 3-4-5. 6*7 :8. 9 Oecd. 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

lo oo O|L|R|RSV|FRG| LEN | Sequence number 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure 3. Structure of the SAToP Control Word 


The use of Bits 0 to 3 is described in [RFC4385]. These bits MUST be 
set to zero unless they are being used to indicate the start of an 
Associated Channel Header (ACH). An ACH is needed if the state of 
the SAToP PW is being monitored using Virtual Circuit Connectivity 
Verification [PWE3-VCCV]. 


L - If set, indicates that TDM data carried in the payload is invalid 
due to an attachment circuit fault. When the L bit is set the 
payload MAY be omitted in order to conserve bandwidth. The CE- 
bound IWF MUST play out an appropriate amount of filler data 
regardless of the payload size. Once set, if the fault is 
rectified, the L bit MUST be cleared. 


Note: This document does not specify which TDM fault conditions are 
treated as invalidating the data carried in the SAToP packets. 
Possible examples include, but are not limited to LOS and AIS. 


R - If set by the PSN-bound IWF, indicates that its local CE-bound 
IWF is in the packet loss state, i.e., has lost a preconfigured 
number of consecutive packets. The R bit MUST be cleared by the 
PSN-bound IWF once its local CE-bound IWF has exited the packet 
loss state, i.e., has received a preconfigured number of 
consecutive packets. 
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RSV and FRG (bits 6 to 9) - MUST be set to 0 by the PSN-bound IWF and 
MUST be ignored by the CE-bound IWF. RSV is reserved. FRG is 
fragmentation; see [PWE3-FRAG]. 


LEN (bits 10 to 15) - MAY be used to carry the length of the SAToP 
packet (defined as the size of the SAToP header + the payload 
Size) if it is less than 64 bytes, and MUST be set to zero 
otherwise. When the LEN field is set to 0, the preconfigured 
Size of the SAToP packet payload MUST be assumed to be as 
described in Section 5.1, and if the actual packet size is 
inconsistent with this length, the packet MUST be considered 
malformed. 


Sequence number - used to provide the common PW sequencing function 
as well as detection of lost packets. It MUST be generated in 
accordance with the rules defined in Section 5.1 of [RFC3550] for 
the RTP sequence number: 


O Its space is a 16-bit unsigned circular space 
o Its initial value SHOULD be random (unpredictable). 


It MUST be incremented with each SAToP data packet sent in the 
Specific PW. 


4.3.2. Usage of RTP Header 

When RTP is used, the following fields of the fixed RTP header (see 

[RFC3550], Section 5.1) MUST be set to zero: P (padding), X (header 

extension), CC (CSRC count), and M (marker). 

The PT (payload type) field is used as follows: 

1. One PT value MUST be allocated from the range of dynamic values 

(see [RTP-TYPES]) for each direction of the PW. The same PT 
value MAY be reused for both directions of the PW and also 


reused between different PWs. 


2. The PSN-bound IWF MUST set the PT field in the RTP header to 
the allocated value. 


3. The CE-bound IWF MAY use the received value to detect malformed 
packets. 


The sequence number MUST be the same as the sequence number in the 
SAToP control word. 
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De 


5; 


The RTP timestamps are used for carrying timing information over the 
network. Their values are generated in accordance with the rules 
established in [RFC3550]. 


The frequency of the clock used for generating timestamps MUST be an 
integer multiple of 8 kHz. All implementations of SAToP MUST support 
the 8 kHz clock. Other multiples of 8 kHz MAY be used. 


The SSRC (synchronization source) value in the RTP header MAY be used 
for detection of misconnections, i.e., incorrect interconnection of 
attachment circuits. 


Timestamp generation MAY be used in the following modes: 


1. Absolute mode: The PSN-bound IWF sets timestamps using the 
clock recovered from the incoming TDM attachment circuit. Asa 
consequence, the timestamps are closely correlated with the 
sequence numbers. All SAToP implementations that support usage 
of the RTP header MUST support this mode. 

2. Differential mode: Both IWFs have access to a common high- 
quality timing source, and this source is used for timestamp 
generation. Support of this mode is OPTIONAL. 


Usage of the fixed RTP header in a SAToP PW and all the options 
associated with its usage (the timestamping clock frequency, the 
timestamping mode, selected PT and SSRC values) MUST be agreed upon 
between the two SAToP IWFs during PW setup as described in 
[TDM-CONTROL]. Other, RTP-specific methods (e.g., see [RFC3551]) 
MUST NOT be used. 


SAToP Payload Layer 
1. General Payloads 


In order to facilitate handling of packet loss in the PSN, all 
packets belonging to a given SAToP PW are REQUIRED to carry a fixed 
number of bytes filled with TDM data received from the attachment 
circuit. The packet payload size MUST be defined during the PW 
setup, MUST be the same for both directions of the PW, and MUST 
remain unchanged for the lifetime of the PW. 


The CE-bound and PSN-bound IWFs MUST agree on SAToP packet payload 
size during PW setup (default payload size values defined below 
guarantee that such an agreement is always possible). The SAToP 
packet payload size can be exchanged over the PWE3 control protocol 
([TDM-CONTROL]) by using the Circuit Emulation over Packet (CEP)/TDM 
Payload Bytes sub-TLV of the Interface Parameters TLV ([RFC4446]). 
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SAToP uses the following ordering for packetization of the TDM data: 


o The order of the payload bytes corresponds to their order on 
the attachment circuit. 


o Consecutive bits coming from the attachment circuit fill each 
payload byte starting from most significant bit to least 
significant. 


All SAToP implementations MUST be capable of supporting the following 
payload sizes: 


o El - 256 bytes 
o T1 - 192 bytes 
o E3 and T3 - 1024 bytes. 


Notes: 


1. Whatever the selected payload size, SAToP does not assume 
alignment to any underlying structure imposed by TDM framing 
(byte, frame, or multiframe alignment). 

2. When the L bit in the SAToP control word is set, SAToP packets 
MAY omit invalid TDM data in order to conserve PSN bandwidth. 

3. Payload sizes that are multiples of 47 bytes MAY be used in 
conjunction with unstructured ATM-CES [ATM-CES]. 


5.2. Octet-Aligned T1 


An unstructured T1 attachment circuit is sometimes provided already 
padded to an integer number of bytes, as described in Annex B of 
[G.802]. This occurs when the Tl is de-mapped from a SONET/SDH 
virtual tributary/container, or when it is de-framed by a dual-mode 
El/T1 framer. 


In order to facilitate operation in such cases, SAToP defines a 
Special "octet-aligned T1" transport mode. In this mode, the SAToP 
payload consists of a number of 25-byte subframes, each subframe 
carrying 193 bits of TDM data and 7 bits of padding. This mode is 
depicted in Figure 4 below. 
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| ii | 2 NTC | 25 | 

|01234567|01234567| nes |01234567 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
TDM Data | padding 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| TDM Data | padding 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure 4. SAToP Payload Format for Octet-Aligned T1 Transport 
Notes: 


1. No alignment with the framing structure that may be imposed on the 
T1 bit-stream is implied. 

2. An additional advantage of the octet-aligned T1 transport mode is 
the ability to select the SAToP packetization latency as an 
arbitrary integer multiple of 125 microseconds. 


Support of the octet-aligned T1 transport mode is OPTIONAL. An 
octet-aligned T1 SAToP PW is not interoperable with a T1 SAToP PW 
that carries a non-aligned bit-stream, as described in the previous 
section. 
Implementations supporting octet-aligned T1 transport mode MUST be 
capable of supporting a payload size of 200 bytes (i.e., a payload of 
eight 25-byte subframes) corresponding to precisely 1 millisecond of 
TDM data. 

6. SAToP Operation 

6.1. Common Considerations 
Edge-to-edge emulation of a TDM service using SAToP is only possible 
when the two PW attachment circuits are of the same type (Tl, El, T3, 
E3). The service type is exchanged at PW setup as described in 
[RFC4447]. 

6.2. IWF Operation 

6.2.1. PSN-Bound Direction 
Once the PW is set up, the PSN-bound SAToP IWF operates as follows: 


TDM data is packetized using the configured number of payload bytes 
per packet. 
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Sequence numbers, flags, and timestamps (if the RTP header is used) 
are inserted in the SAToP headers. 


SAToP, PW demultiplexing layer, and PSN headers are prepended to the 
packetized service data. 


The resulting packets are transmitted over the PSN. 
6.2.2.  CE-Bound Direction 


The CE-bound SAToP IWF SHOULD include a jitter buffer where the 
payload of the received SAToP packets is stored prior to play-out to 
the local TDM attachment circuit. The size of this buffer SHOULD be 
locally configurable to allow accommodation to the PSN-specific 
packet delay variation. 


The CE-bound SAToP IWF SHOULD use the sequence number in the control 
word for detection of lost and misordered packets. If the RTP header 
is used, the RTP sequence numbers MAY be used for the same purposes. 


Note: With SAToP, a valid sequence number can be always found in bits 
16 - 31 of the first 32-bit word immediately following the PW 
demultiplexing header regardless of the specific PSN type, 
multiplexing method, usage or non-usage of the RTP header, etc. This 
approach simplifies implementations supporting multiple encapsulation 
types as well as implementation of multi-segment (MS) PWs using 
different encapsulation types in different segments. 


The CE-bound SAToP IWF MAY reorder misordered packets.  Misordered 
packets that cannot be reordered MUST be discarded and treated as 
lost. 


The payload of the received SAToP packets marked with the L bit set 
SHOULD be replaced by the equivalent amount of the "all ones" pattern 
even if it has not been omitted. 


The payload of each lost SAToP packet MUST be replaced with the 
equivalent amount of the replacement data. The contents of the 
replacement data are implementation-specific and MAY be locally 
configurable. By default, all SAToP implementations MUST support 
generation of the "all ones" pattern as the replacement data. Before 
a PW has been set up and after a PW has been torn down, the IWF MUST 
play out the "all ones" pattern to its TDM attachment circuit. 


Once the PW has been set up, the CE-bound IWF begins to receive SAToP 
packets and to store their payload in the jitter buffer but continues 
to play out the "all ones" pattern to its TDM attachment circuit. 

This intermediate state persists until a preconfigured amount of TDM 
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data (usually half of the jitter buffer) has been received in 
consecutive SAToP packets or until a preconfigured intermediate state 
timer (started when the PW setup is completed) expires. 


Once the preconfigured amount of the TDM data has been received, the 
CE-bound SAToP IWF enters its normal operation state where it 
continues to receive SAToP packets and to store their payload in the 
jitter buffer while playing out the contents of the jitter buffer in 
accordance with the required clock. In this state, the CE-bound IWF 
performs clock recovery, MAY monitor PW defects, and MAY collect PW 
performance monitoring data. 


If the CE-bound SAToP IWF detects loss of a preconfigured number of 
consecutive packets or if the intermediate state timer expires before 
the required amount of TDM data has been received, it enters its 
packet loss state. While in this state, the local PSN-bound SAToP 
IWF SHOULD mark every packet it transmits with the R bit set. The 
CE-bound SAToP IWF leaves this state and transitions to the normal 
one once a preconfigured number of consecutive valid SAToP packets 
have been received. (Successfully reordered packets contribute to 
the count of consecutive packets.) 


The CE-bound SAToP IWF MUST provide an indication of TDM data 
validity to the CE. This can be done by transporting or by 
generating the native AIS indication. As mentioned above, T3 AIS 
cannot be detected or generated by structure-agnostic means, and 
hence a structure-aware NSP MUST be used when generating a valid AIS 
pattern. 


6.3. SAToP Defects 


In addition to the packet loss state of the CE-bound SAToP IWF 
defined above, it MAY detect the following defects: 


Stray packets 

Malformed packets 
Excessive packet loss rate 
Buffer overrun 

Remote packet loss 


00000 


Corresponding to each defect is a defect state of the IWF, a 
detection criterion that triggers transition from the normal 
operation state to the appropriate defect state, and an alarm that 
MAY be reported to the management system and thereafter cleared. 
Alarms are only reported when the defect state persists for a 
preconfigured amount of time (typically 2.5 seconds) and MUST be 
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cleared after the corresponding defect is undetected for a second 
preconfigured amount of time (typically 10 seconds). The trigger and 
release times for the various alarms may be independent. 


Stray packets MAY be detected by the PSN and PW demultiplexing 
layers. When RTP is used, the SSRC field in the RTP header MAY be 
used for this purpose as well. Stray packets MUST be discarded by 
the CE-bound IWF, and their detection MUST NOT affect mechanisms for 
detection of packet loss. 


Malformed packets are detected by mismatch between the expected 
packet size (taking the value of the L bit into account) and the 
actual packet size inferred from the PSN and PW demultiplexing 
layers. When RTP is used, lack of correspondence between the PT 
value and that allocated for this direction of the PW MAY also be 
used for this purpose. Malformed in-order packets MUST be discarded 
by the CE-bound IWF and replacement data generated as with lost 
packets. 


Excessive packet loss rate is detected by computing the average 
packet loss rate over a configurable amount of times and comparing it 
with a preconfigured threshold. 


Buffer overrun is detected in the normal operation state when the 
jitter buffer of the CE-bound IWF cannot accommodate newly arrived 
SAToP packets. 


Remote packet loss is indicated by reception of packets with their R 
bit set. 


6.4. SAToP PW Performance Monitoring 


Performance monitoring (PM) parameters are routinely collected for 
TDM services and provide an important maintenance mechanism in TDM 
networks. The ability to collect compatible PM parameters for SAToP 
PWs enhances their maintenance capabilities. 


Collection of the SAToP PW performance monitoring parameters is 
OPTIONAL and, if implemented, is only performed after the CE-bound 
IWF has exited its intermediate state. 


SAToP defines error events, errored blocks, and defects as follows: 
O A SAToP error event is defined as insertion of a single 
replacement packet into the jitter buffer (replacement of 


payload of SAToP packets with the L bit set is not considered 
insertion of a replacement packet). 
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o A SAToP errored data block is defined as a block of data played 
out to the TDM attachment circuit and of a size defined in 
accordance with the [G.826] rules for the corresponding TDM 
service that has experienced at least one SAToP error event. 


o A SAToP defect is defined as the packet loss state of the 
CE-bound SAToP IWF. 


The SAToP PW PM parameters (Errored, Severely Errored, and 
Unavailable Seconds) are derived from these definitions in accordance 
with [G.826]. 


7. Quality of Service (00S) Issues 
SAToP SHOULD employ existing QoS capabilities of the underlying PSN. 


If the PSN providing connectivity between PE devices is Diffserv- 
enabled and provides a PDB [RFC3086] that guarantees low jitter and 
low loss, the SAToP PW SHOULD use this PDB in compliance with the 
admission and allocation rules the PSN has put in place for that PDB 
(e.g., marking packets as directed by the PSN). 


If the PSN is Intserv-enabled, then GS (Guaranteed Service) [RFC2212] 
with the appropriate bandwidth reservation SHOULD be used in order to 
provide a bandwidth guarantee equal or greater than that of the 
aggregate TDM traffic. 


8. Congestion Control 


As explained in [RFC3985], the PSN carrying the PW may be subject to 
congestion.  SAToP PWs represent inelastic constant bit-rate (CBR) 
flows and cannot respond to congestion in a TCP-friendly manner 
prescribed by [RFC2914], although the percentage of total bandwidth 
they consume remains constant. 


Unless appropriate precautions are taken, undiminished demand of 
bandwidth by SAToP PWs can contribute to network congestion that may 
impact network control protocols. 


Whenever possible, SAToP PWs SHOULD be carried across traffic- 
engineered PSNs that provide either bandwidth reservation and 
admission control or forwarding prioritization and boundary traffic 
conditioning mechanisms.  IntServ-enabled domains supporting 
Guaranteed Service (GS) [RFC2212] and DiffServ-enabled domains 
[RFC2475] supporting Expedited Forwarding (EF) [RFC3246] provide 
examples of such PSNs. Such mechanisms will negate, to some degree, 
the effect of the SAToP PWs on the neighboring streams. In order to 
facilitate boundary traffic conditioning of SAToP traffic over IP 


Vainshtein & Stein Standards Track [Page 16] 


RFC 4553 Structure-Agnostic TDM over Packet June 2006 


PSNs, the SAToP IP packets SHOULD NOT use the DiffServ Code Point 
(DSCP) value reserved for the Default Per-Hop Behavior (PHB) 
[RFC2474]. 


If SAToP PWs run over a PSN providing best-effort service, they 
SHOULD monitor packet loss in order to detect "severe congestion". 
If such a condition is detected, a SAToP PW SHOULD shut down bi- 
directionally for some period of time as described in Section 6.5 of 
[RFC3985]. 


Note that: 


1. The SAToP IWF can inherently provide packet loss measurement since 
the expected rate of arrival of SAToP packets is fixed and known 


2. The results of the SAToP packet loss measurement may not be a 
reliable indication of presence or absence of severe congestion if 
the PSN provides enhanced delivery. For example: 


a) If SAToP traffic takes precedence over non-SAToP traffic, 
severe congestion can develop without significant SAToP packet 
loss. 


b) I£ non-SAToP traffic takes precedence over SAToP traffic, SAToP 
may experience substantial packet loss due to a short-term 
burst of high-priority traffic. 


3. The TDM services emulated by the SAToP PWs have high availability 
objectives (see [G.826]) that MUST be taken into account when 
deciding on temporary shutdown of SAToP PWs. 


This specification does not define the exact criteria for detecting 
"severe congestion" using the SAToP packet loss rate or the specific 
methods for bi-directional shutdown the SAToP PWs (when such severe 
congestion has been detected) and their subsequent re-start after a 
suitable delay. This is left for further study. However, the 
following considerations may be used as guidelines for implementing 
the SAToP severe congestion shutdown mechanism: 


1. SAToP Performance Monitoring techniques (see Section 6.4) provide 
entry and exit criteria for the SAToP PW "Unavailable" state that 
make it closely correlated with the "Unavailable" state of the 
emulated TDM circuit as specified in [G.826]. Using the same 
criteria for "severe congestion" detection may decrease the risk 
of shutting down the SAToP PW while the emulated TDM circuit is 
still considered available by the CE. 
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10. 


2. If the SAToP PW has been set up using either PWE3 control protocol 
[RFC4447] or L2TPv3 [RFC3931], the regular PW teardown procedures 
of these protocols SHOULD be used. 


3. I£ one of the SAToP PW end points stops transmission of packets 
for a sufficiently long period, its peer (observing 100% packet 
loss) will necessarily detect "severe congestion" and also stop 
transmission, thus achieving bi-directional PW shutdown. 


Security Considerations 
SAToP does not enhance or detract from the security performance of 


the underlying PSN; rather, it relies upon the PSN mechanisms for 
encryption, integrity, and authentication whenever required. 


SAToP PWs share susceptibility to a number of pseudowire-layer 
attacks and will use whatever mechanisms for confidentiality, 
integrity, and authentication are developed for general PWs. These 
methods are beyond the scope of this document. 


Although SAToP PWs MAY employ an RTP header when explicit transfer of 
timing information is required, SRTP (see [RFC3711]) mechanisms are 
NOT RECOMMENDED as a substitute for PW layer security. 


Misconnection detection capabilities of SAToP increase its resilience 
to misconfiguration and some types of denial-of-service (DoS) 
attacks. 


Random initialization of sequence numbers, in both the control word 
and the optional RIP header, makes known-plaintext attacks on 
encrypted SAToP PWs more difficult. Encryption of PWs is beyond the 
scope of this document. 


Applicability Statement 


SAToP is an encapsulation layer intended for carrying TDM circuits 
(E1/T1/E3/T3) over PSN in a structure-agnostic fashion. 


SAToP fully complies with the principle of minimal intervention, thus 
minimizing overhead and computational power required for 
encapsulation. 


SAToP provides sequencing and synchronization functions needed for 
emulation of TDM bit-streams, including detection of lost or 
misordered packets and appropriate compensation. 
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TDM bit-streams carried over SAToP PWs may experience delays 
exceeding those typical of native TDM networks. These delays include 
the SAToP packetization delay, edge-to-edge delay of the underlying 
PSN, and the delay added by the jitter buffer. It is recommended to 
estimate both delay and delay variation prior to setup of a SAToP PW. 


SAToP carries TDM streams over PSN in their entirety, including any 
TDM signaling contained within the data. Consequently, the emulated 
TDM services are sensitive to the PSN packet loss. Appropriate 
generation of replacement data can be used to prevent shutting down 


the CE TDM interface due to occasional packet loss. Other effects of 
packet loss on this interface (e.g., errored blocks) cannot be 
prevented. 


Note: Structure-aware TDM emulation (see [CESoPSN] or [TDMoIP]) 
completely hides effects of the PSN packet loss on the CE TDM 
interface (because framing and Cyclic Redundancy Checks (CRCs) are 
generated locally) and allows usage of application-specific packet 
loss concealment methods to minimize effects on the applications 
using the emulated TDM service. 


SAToP can be used in conjunction with various network synchronization 


scenarios (see [RFC4197]) and clock recovery techniques. The quality 
of the TDM clock recovered by the SAToP IWF may be implementation- 
specific. The quality may be improved by using RTP if a common clock 


is available at both ends of the SATOP PW. 


SAToP provides for effective fault isolation by carrying the local 
attachment circuit failure indications. 


The option not to carry invalid TDM data enables PSN bandwidth 
conservation. 


SAToP allows collection of TDM-like faults and performance monitoring 
parameters and hence emulates 'classic' carrier services of TDM. 


SAToP provides for a carrier-independent ability to detect 


misconnections and malformed packets. This feature increases 
resilience of the emulated service to misconfiguration and DoS 
attacks. 


Being a constant bit rate (CBR) service, SAToP cannot provide TCP- 
friendly behavior under network congestion. 


Faithfulness of a SAToP PW may be increased by exploiting QoS 
features of the underlying PSN. 
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SAToP does not provide any mechanisms for protection against PSN 
outages, and hence its resilience to such outages is limited. 
However, lost-packet replacement and packet reordering mechanisms 
increase resilience of the emulated service to fast PSN rerouting 
events. 


11. IANA Considerations 


Allocation of PW Types for the corresponding SAToP PWs is defined in 
[RFC4446]. 
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Appendix A: Old Mode of SAToP Encapsulation over L2TPv3 


Previous versions of this specification defined a SAToP PW 
encapsulation over L2TPv3, which differs from that described in 
Section 4.3 and Figure 2b. In these versions, the RTP header, if 
used, precedes the SAToP control word. 


Existing implementations of the old encapsulation mode MUST be 
distinguished from the encapsulations conforming to this 
specification via the SAToP PW setup. 


Appendix B: Parameters That MUST Be Agreed upon during the PW Setup 


The following parameters of the SAToP IWF MUST be agreed upon between 
the peer IWFs during the PW setup. Such an agreement can be reached 
via manual configuration or via one of the PW setup protocols: 


1. Type of the Attachment Circuit (AC) 


As mentioned in Section 3, SAToP supports the following AC types: 
i) El (2048 kbit/s 
ii) T1 (1544 kbit/s 
iii) E3 (34368 kbit/s 
iv) T3 (44736 kbit/s 


; this service is also known as DS1 


— x x wa 


; this service is also known as DS3 
SAToP PWs cannot be established between ACs of different types. 
2. Usage of octet-aligned mode for Tl 


a) This OPTIONAL mode of emulating T1 bit-streams with SAToP PWs 
is described in Section 5.2. 


b) Both sides MUST agree on using this mode for a SAToP PW to be 
operational. 


3. Payload size, i.e., the amount of valid TDM data in a SAToP packet 


a) As mentioned in Section 5.1: 
i) The same payload size MUST be used in both directions of 
the SAToP PW. 
ii) The payload size cannot be changed once the PW has been set 
up. 


b) In most cases, any mutually agreed upon value can be used. 
However, if octet-aligned T1 encapsulation mode is used, the 
payload size MUST be an integral multiple of 25, and it 
expresses the amount of valid TDM data including padding. 
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4. Usage of the RTP header in the encapsulation 
a) Both sides MUST agree on using RTP header in the SAToP PW. 


b) In the case of a SAToP PW over L2TPv3 using the RTP header, 
both sides MUST agree on usage of the "old mode" described in 
Appendix A. 


5. RIP-dependent parameters. The following parameters MUST be agreed 
upon if usage of the RTP header for the SAToP PW has been agreed 
upon. 


a) Timestamping mode (absolute or differential); this mode MAY be 
different for the two directions of the PW, but the receiver 
and transmitter MUST agree on the timestamping mode for each 
direction of the PW 


b) Timestamping clock frequency: 

i) The timestamping frequency MUST be a integral multiple of 8 
kHz. 

ii) The timestamping frequency MAY be different for the two 
directions of the PW, but the receiver and transmitter MUST 
agree on the timestamping mode for each direction of the 
PW. 


c) RIP Payload Type (PT) value; any dynamically assigned value can 
be used with SAToP PWs. 


d) Synchronization Source (SSRC) value; the transmitter MUST agree 
to send the SSRC value requested by the receiver. 


Vainshtein & Stein Standards Track [Page 25] 


RFC 4553 Structure-Agnostic TDM over Packet June 2006 


Editors’ Addresses 


Alexander ("Sasha") Vainshtein 
Axerra Networks 

24 Raoul Wallenberg St., 

Tel Aviv 69719, Israel 


EMail: sasha@axerra.com 


Yaakov (Jonathan) Stein 

RAD Data Communications 

24 Raoul Wallenberg St., Bldg C 
Tel Aviv 69719, Israel 


EMail: yaakov_s@rad.com 


Vainshtein & Stein Standards Track [Page 26] 


RFC 4553 Structure-Agnostic TDM over Packet June 2006 


Full Copyright Statement 
Copyright (C) The Internet Society (2006). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
ietf-ipr@ietf.org. 


Acknowledgement 


Funding for the RFC Editor function is provided by the IETF 
Administrative Support Activity (IASA). 


Vainshtein & Stein Standards Track [Page 27] 


